DAY30 淺談 Azure Machine Learning 的 MLOps 做法

終於來到最後一天，我們學完了整套 Azure Machine Learning 的基礎用法了，最後我們來談談 MLOps 的部分吧！

「每個來跟我談 MLOps 的，都只是想要賣我工具！」

之前筆者在客戶做專案時，和客戶聊到了 MLOps，客戶就說：「每個來跟我談 MLOps 的，都只是想要賣我他們開發或是代理的工具！」這句話真的很有意思，因為要做好 MLOps，真的不能缺少工具。

根據 ml-ops.org 網站裡所寫的，在建構一個 MLOps 環境時，有幾個 Component 是不可或缺，而這些 Component 有都著對應的工具：

1. Source control：
這個最沒有爭議，版本控制就是 MLOps 的基礎，也是 DevOps 的基礎。在 AML 裡也是可以使用 git 做版本控制，但是除了程式碼以外，資料集、模型等等的，也是需要做版本控制的。資料集和模型在 AML 裡的版本控制，我們也在過去 30 天裡面學到了。

2. CI/CD service：
在微軟的生態系裡，CI/CD 服務主要會採用 Azure DevOps 這項服務來建構，當然這項服務也可以整合到 AML 之中。不過短短的 30 天內難以涵蓋到這部份，未來或許還有機會和讀者們分享這一塊的知識。

3. Model Registry：
要導入 MLOps，模型的管理是非常重要的。這項功能我們也在 AML 裡也是有的，而且我們再過去的 30 天裡一再地看到。

4. Feature Store：
我們在做資料前處理時得到的 feature，要可以存起來，並可以在模型訓練時的 Pipeline 裡使用。還記得我們在講 Pipeline 時教過的 OutputFileDatasetConfig 嗎？這就是一種 Feature store 的作法。

5. ML Metadata Store：
我們要可以追蹤模型訓練時的 metadata，包含了參數、超參數、metrics 等等的訊息，甚至要可以重現我們的模型。我們在教 SDK 的過程中，教過了 Run、MLflow、hyperdrive、還有 Application Insights 等等的功能，都是可以達成這項目的的哦！

6. ML Pipeline Orchestrator：
這個是在講 Pipeline 步驟的自動化。我們之前也教過 PythonScriptStep，以及其自動化的方式啦！

這樣看下來，有沒有覺得 AML 真的是 MLOps 很棒的工具？把我們做 MLOps 所需要的功能都提供了呢！

微軟的 MLOps maturity model

再來談談微軟寫的 MLOps 成熟度模型的五個等級吧！

0. No MLOps：
恩，就是都手動人工來做。

1. DevOps but no MLOps：
這個階段已經開始導入 DevOps 了，可是對於 AI 模型和環境的管理還很差，也很難重現訓練出來的模型。

2. Automated Training：
訓練的環境已經完全受控和可追蹤，也可以重現訓練出來的模型，但是 release 還是手動的。

3. Automated Model Deployment：
基本上已經都自動化，並且可以追蹤。有完整的訓練、測試、生產的環境了。

4. Full MLOps Automated Operations：
整個環境都是自動且易於監控的，並且生產系統能提供改善的資訊、甚至有些時候自動改善。系統可以接近零停機。

雖然很多公司初期導入 AI，都會在 0 級或是 1 級。但是 MLOps 是企業大規模導入 AI 一定要走的路，如果你公司只打算導入一個 AI 專案並且就此停住，或許可以考慮不用 MLOps，但是這是不可能的事情（如果真的有，建議快點換工作）。大家就盡可能利用 AML 的優勢，把自己的公司的 MLOps 成熟度升級吧！

結語

這是我第一次參加鐵人賽，沒想到居然完賽了，真的很感動。

這段日子我很難熬，因為女兒剛出生，事情超級多超級忙。而且剛出生的寶寶會在半夜哭鬧，我都半夜爬起來餵奶，餵完奶哄寶寶睡了之後，就開始寫鐵人賽的文章。真的寫得很累很辛苦，尤其我又希望圖文並茂，每篇文章都是親自實作並且截圖的。後半段在寫 AML SDK 時，也堅持每段程式碼都跑過。第一次寫鐵人賽真的不小心把格局弄得太大，差點沒把自己操死。還好看到女兒和老婆安詳的睡眠，我也就有繼續努力的動力了。

再來是做為現役的 Microsoft AI MVP，我覺得我有義務把這麼好的工具分享給大家，希望大家可以在導入 AI 的過程中，可以更加的順利。這樣子的信念也支持了我寫完這 30 天的動力吧！